Awesome work 👍

I had a thought about how we could approach this feature. It shares a lot of similarities with the protocol callback work I did in #449 - both escaping closures and protocols are a way to achieve callbacks.

Consider the following API

func f(closure: @escaping (Int64, MyClass) -> Void)

technically we could express this as:

protocol f_closure {
    func apply(_ arg0: Int64, _ arg1: MyClass)
 }

func f(_ closureObject: f_closure) {
    self.f {
        closureObject.apply($0, $1)
    }
 }

then if we could pass the f_closure protocol and the new helper-function f through the work I did in the protocol PR, then it would generate

interface f_closure {
  void apply(long arg0, MyClass arg1)
}

private static void f(f_closure_protocol closure_protocol) {
  // Downcall to Swift that takes in the protocol
  $f(closure_protocol)
}

and the required Swift wrappers needed to call that interface from Swift.
Now, we could detect that the protocol is used as a closure, and just attach @FunctionalInterface to it

@FunctionalInterface
interface f_closure {
  void apply(long arg0, MyClass arg1)
}

public static void f($f_closure closure) {
  // Call the`f` that takes in the "f_closure" Swift protocol:
  f($f_closure);
 }

Then we basically have achieved support for escaping closures, by "proxying" them through protocols. This means we don't have to do double the work when we need to add new features to either protocols or closures. For example, this would give us support for non-primitive types right away, since protocols already support them.

Let me know what you think!